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Abstract —  Emergency  response  operations  would  universally 
benefit  by  extending  telemedicine  to  the  most  difficult  and 
challenging  environments.  For  example,  the  Air  Force 
Pararescue  Jumpers  (PJ)  and  Combat  Rescue  Officers  (CRO) 
perform  rescue  and  life-saving  measure  in  austere  environments. 
Currently,  Bluetooth®  aided  pen-and-paper  systems  are 
employed  to  collect  and  store  medical  data,  from  the  time  it  is 
sensed  to  its  dissemination.  This  is  proving  to  be  tedious  and  non- 
scalable,  especially  when  the  number  of  casualties  is  larger  than 
the  number  of  responders  in  a  given  mission.  Pararescue 
Jumpers,  Combat  Rescue  Officers  and  similar  medical  rescue 
agencies  are  seeking  medical  vital  sign  sensors  and  telemetry 
solutions  for  mass  casualty  responses  in  which  a  small  team  of 
medical  rescuers  must  be  able  to  rescue  and  sustain  the  life  of 
multiple  casualties  in  critical  condition. 

Project  Ripple,  to  be  described  in  this  paper,  is  meant  to 
create  a  Medical  Body  Area  Network  (MBAN)  of  sensors  to  assist 
in  triage  and  general  physiological  data  collection  in  a  disaster 
scenario.  The  system  is  demonstrates  an  improved  alternative  to 
existing  Bluetooth®  and  pen-and-paper  systems  by  streamlining 
the  processes  of  data  collection,  storage,  transfer,  and 
visualization.  Low-power,  wireless  devices  that  utilized  open 
standards  makeup  the  sensor  network  while  custom  mobile 
applications  were  used  for  the  visualization  of  the  sensor  data. 
Also,  flexible  and  generic  sensor  fusion  architecture  is  being 
explored. 

Keywords — MBAN;  sensor  fusion ;  pararescue 

I.  Introduction 

Emergency  response  operations  would  universally  benefit 
by  extending  telemedicine  to  the  most  difficult  and  challenging 
environments.  For  example,  the  Air  Force  Pararescue  Jumpers 
(PJ)  and  Combat  Rescue  Officers  (CRO)  perform  rescue  and 
life-saving  measure  in  austere  environments.  In  the  most  recent 
conflicts,  they  are  often  called  upon  to  respond  to  IED  blasts, 
rocket  attacks,  or  helicopter  crashes.  In  other  circumstances 
they  are  often  involved  in  humanitarian  response  to  natural 
disasters.  We  are  currently  seeking  medical  vital  sign  sensors 
and  telemetry  solutions  for  mass  casualty  responses  in  which  a 
small  team  of  Pararescue  Jumpers  must  be  able  to  rescue  and 


sustain  the  life  of  multiple  casualties  in  critical  condition.  The 
future  medical  sensing  solutions  will  be  small  and  lightweight, 
allowing  the  PJ  to  easily  transport  the  devices  to  multiple 
patients.  They  will  assist  the  lead  PJ  by  providing  real  time 
status  of  all  patients  so  that  resources  can  be  best  prioritized  to 
save  as  many  lives  as  possible  and  to  facilitate  rapid  extrication 
and  transport  of  the  casualties. 

Additionally,  designs  based  on  emerging  and  open 
standards  will  make  patient  data  available  to  all  stakeholders  in 
near  real-time  through  advancements  in  ubiquitous  and  cloud 
computing.  The  fusion  of  sensor  data  and  other  information 
will  improve  command  and  control  during  incident  response 
and  will  allow  patient  data  to  be  available  to  the  receiving 
emergency  facilities  prior  to  patient  arrival.  Predictive  medical 
systems  will  use  this  sensor  data  and  play  an  increasing  role 
throughout  the  chain  of  patient  care. 

Ripple  is  a  testbed  for  using  physiological  sensors  to 
facilitate  improved  emergency  response  using  ubiquitous  and 
cloud  computing  technologies.  The  first  stage  of  the  project, 
presented  in  this  paper,  focuses  on  optimizing  communication 
between  wireless  physiological  sensors  and  patient  monitoring 
devices  used  by  emergency  responders.  The  objective  is  to 
increase  situation  awareness  with  little  additional  effort  on  the 
part  of  the  task  saturated  responder. 

The  traditional  tools  for  evaluating  and  monitoring  patients 
in  a  mass  casualty  event  are  triage  tags,  which  are  hand  written 
tags  that  help  the  responder  quickly  document  a  patient 
assessment.  Vital  signs  measurements  are  limited  to  those  that 
can  be  manually  measured  by  the  responder  without  any 
sophisticated  equipment,  e.g.  pulse  and  respiration  rate. 

Advances  in  wireless  communications  and  miniaturization 
of  electronics  has  led  to  the  development  and 
commercialization  of  compact,  wearable  sensors  that  can 
continuously  monitor  some  patient  vital  signs.  Our  discussion 
with  early  adopters  of  these  systems  has  revealed  that  the 
currently  utilized  wireless  technologies  interferes  with  their 
ability  to  efficiently  monitor  patients  in  all  environments 
except  those  where  a  fixed  wireless  infrastructure  can  be 
established.  Most  systems  that  are  being  tested  for  emergency 
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response  utilize  Bluetooth®  because  it  is  low  power  and  allows 
any  available  smartphone  or  tablet  device  to  be  used  for  patient 
monitoring.  During  a  patient  hand-off,  which  occurs  frequently 
and  rapidly  in  a  mass  casualty  response,  a  Bluetooth®  device 
needs  to  be  manually  un-paired  with  the  current  monitoring 
device  and  paired  with  the  monitoring  devices  of  the  next 
responder.  If  there  are  multiple  Bluetooth®  devices  in  range 
during  the  pairing,  it  can  be  difficult  to  quickly  identify  the 
device  of  interest. 

What  is  needed  for  emergency  response  is  to  form  a 
network  of  sensors  and  monitoring  devices  in  which  each  and 
every  monitoring  device  is  capable  of  receiving  data  from  each 
and  every  sensor.  The  existing  systems  which  are  capable  of 
this  are  better  suited  for  use  in  hospitals  where  a  reliable 
network  infrastructure  can  be  maintained. 

II.  System  Architecture 


•  User  applications:  All  stakeholders  will  need  patient 
data  to  be  visualized  and  managed  by  applications  that 
support  the  performance  of  their  mission.  The  rescue 
personnel  require  applications  that  allow  them  to 
monitor  all  patients  on  a  scene  at  once,  or  to  look  at  a 
single  patient  in  more  detail  and  to  manually  add 
additional  information  to  a  patient's  medical  record. 

B.  Stage  I  Architecture 

The  first  iteration  of  Ripple  focused  on  the  network  of 
physiological  sensors  and  responder  monitoring  devices.  The 
primary  objective  was  to  prove  a  suitable  alternative  to  the 
Bluetooth  technology  that  limits  the  effectiveness  of  existing 
systems.  A  sensor  network  utilizing  802.15.4  [1]  radios  and 
IPv6  over  Low  power  Wireless  Personal  Area  Networks 
(6L0WPAN)  was  chosen.  Table  1  summarizes  the 
requirements  supporting  this  selection 


A.  Exemplary  Architecture 

Ripple  is  a  test-bed  that  allows  us  to  experiment  with  a 
variety  of  subsystems  to  enable  ubiquitous  and  reliable 
physiological  monitoring  in  a  mass  casualty  or  disaster 
response.  A  specific  architecture  for  this  is  not  concretely 
defined  but  a  set  of  core  components  is  required.  We  have 
categorized  these  subsystems  into  the  following  taxonomy: 

•  Wireless  patient  sensor  network:  A  network  protocol  is 
needed  that  can  support  a  heterogeneous  collection  of 
sensors  that  can  continue  to  functions  seamlessly  during 
patient  handoffs.  A  network  that  support  any-to-any 
routing  is  ideal  for  this  purpose.  Device  and  service 
discovery  needs  to  be  automated  or  very  efficient  and 
the  wireless  technology  that  is  utilized  needs  to  have 
minimal  power  requirements  in  order  to  facilitate  the 
development  of  small  sensors  that  can  run  unattended 
on  small  batteries  for  the  duration  of  the  rescue  and 
transport. 

•  Mobile  middleware:  Services  will  need  to  be  present  on 
the  local  network  to  facilitate  sharing  of  patient  data  and 
discovery  of  sensors  and  monitors.  Many  ubiquitous 
computing  systems  would  rely  on  connections  to 
remote  cloud  systems  to  accomplish  this,  but  Ripple 
needs  to  support  local  patient  monitoring  when 
connection  to  the  larger  network  or  Internet  is 
disrupted.  It  is  important  that  this  middleware  is  capable 
of  being  used  on  mobile  computing  devices  because  it 
will  need  to  be  transported  and  ideally,  this  middleware 
would  be  capable  of  operating  on  the  computing 
devices  that  are  used  by  the  responders  for  patient 
monitoring. 

•  Cloud  middleware:  Patient  data  can  be  leveraged  by  a 
variety  of  other  stakeholders  through  a  cloud  based 
infrastructure.  A  well  designed  architecture  could 
support  the  sharing  and  fusion  of  patient  data  with 
predictive  systems,  command  and  control  systems,  and 
other  information  management  and  notification 
systems. 
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TABLE  I.  Suitability  of  existing  wireless  technologies  vs 

SYSTEM  REQUIREMENTS 


Bluetooth® 

Proprietary 

IEEE 

802.15.4 

IEEE 

802.11 

6L0WPAN 
with  IEEE 
802.15.4 

Local  any-to-any 
communication 

/ 

/ 

/ 

Standardized 
network  of 
heterogeneous 
devices 

/ 

/ 

/ 

Global  any-to-any 
communications 

/ 

/ 

Ad-hoc  device  and 
service  discovery 

/ 

/ 

/ 

Low  power 

/ 

/ 

/ 

Mobility  tolerance 

/ 

/ 

/ 

6L0WPAN  is  an  IETF  standard  that  provides  an  IPv6 
adaptation  layer  for  low  power  communication  devices, 
particularly  IEEE  802.15.4  devices.  The  result  of  employing 
this  architecture  is  a  wireless  network  of  low  power  devices 
that  behave  similar  to  IEEE  802.11  devices,  but  with  a  lower 
power  penalty  at  the  expense  of  decreased  throughput  [2]. 

1)  Sensor  System 

Idealized  sensor  platforms  for  emergency  response  are  able 
to  support  the  sensing  of  multiple  signals.  This  reduces  the 
burden  of  transporting  multiple  systems.  For  Ripple,  we 
prototyped  a  system  that  combined  a  pulse  oximeter,  an 
electrocardiogram,  a  temperature  probe,  and  and  ARM  7, 
802.15.4  System-on-Chip  (SoC). 

a)  Ripple  Sensor  Components 
•  Hardware 

o  Thermistor  based  dermal  temperature  probe 

o  Nonin  OEM  III  Module  or  Nonin  XPOD 
Pulse  Oximeters 

o  Nonin  8000  series  PureLight  sensors 

o  Shimmer  Sensing  ECG  Board 
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o  Redwire  LLC  Econotag  MCI 3224  ARM7 
802.15.4  SoC  development  kit 

o  Custom  adapter  board 

•  Software 

o  Contiki-OS 

o  Custom  datagram  transport  application 


2)  Network 

Ripple  Sensors  are  part  of  a  6L0WPAN  network.  The 
network  routing  using  the  Routing  Protocol  for  Low  Power  and 
Lossy  Networks  (RPL)  to  self- form  a  data  acrylic  graphs 
(DAG)  which  are  intended  to  route  traffic  toward  a  limited 
number  of  collection  points  [3].  In  theory,  this  would  allow 
mobile  sensors  to  switch  collection  points  with  limited  loss  of 
connection.  The  collection  points  reside  outside  of  the  link- 
local  RPL  network,  on  a  standard  TCP/IP  network  which  is 
connected  to  the  RPL  network  through  a  6L0WPAN  Border 
Router.  An  example  network  architecture  network  architecture 
including  connections  of  to  middleware  and  monitors  is 
illustrated  in  Fig.  1. 

3)  Middleware 

The  system  primarily  relies  upon  a  brokered 
publish/subscribe  pattern  of  communication  to  ensure  that 
newly  connected  clients  and  sensors  can  quickly  be  discovered 
and  provided  with  needed  information.  Currently,  the  system 
uses  a  centralized  information  broker  which  runs  on  the  same 
hardware  as  the  6L0WPAN  Border  Router,  but  this  is  not 
absolutely  necessary. 

The  Information  Broker  is  a  program  that  acts  as  a 
bridge/buffer  between  the  sensor  network  and  the  responder 
network.  The  broker  serves  two  main  purposes:  local  data 
management  and  communication  between  the  sensor  network 
and  the  responder  network.  This  centralized  framework  was 
used  for  a  couple  reasons:  reduce  processing  on  the  sensors  by 
having  no  direct  requests  from  responder  devices  to  sensors 


and  reduce  traffic  on  the  low-bandwidth  sensor  network  as 
multiple  requests  for  the  same  data  comes  from  the  Broker’s 
buffer  rather  than  directly  from  motes. 

Patient  data  is  stored  in  two  forms  in  the  broker:  a  small, 
temporary  buffer  to  allow  quick  access  to  the  lasts  reading  for  a 
given  patient  and  a  SQL  database  for  archival  purposes.  The 
broker  will  buffer  the  latest  patient  readings  into  an  in-memory 
buffer  to  allow  quick  access  when  responders  requests  real¬ 
time  streams  for  a  specific  patient.  Patient  data  are  archived 
using  a  SQL  database.  The  patient  information,  such  as  id, 
name,  and  ip  address,  is  stored  in  one  table  while  vitals  are 
stored  in  another  table. 

4)  Human  Computer  Interaction 

Mobile  responders  interact  with  patients  connected  to  the 
wireless  medical  sensor  network  by  way  of  the  Ripple  Android 
App  (RAA).  As  the  name  suggests  the  RAA  is  a  native  android 
application,  and  is  intended  to  be  run  on  a  large  display  format 
android-based  device  such  as  a  tablet.  The  RAA  offers  3 
primary  functions  to  the  user:  firstly  the  RAA  acts  as  a  high 
fidelity  platform  for  visualizing  patient  health  information, 
secondly  as  a  network  communication  interface  by  which  a 
responder  can  query  sensor  and  submit  manual  health  data. 
Lastly,  the  RAA  is  capable  of  acting  as  part  of  a  delay  tolerant 
caching  network  of  other  responders.  The  RAA  is  an  integral 
part  of  the  complete  Ripple  system. 

The  primary  feature  of  the  user  interface  is  the 
simultaneous  display  of  basic  patient  information  for  all 
patients,  the  more  detailed  display  of  a  single  patients  medical 
data,  and  a  third  section  that  can  be  used  to  display  geospatial 
data.  A  screenshot  of  the  application  is  shown  in  Fig.  2.  This 
user  interface  concept  is  compliments  the  needs  of  a  responder 
to  a  military  mass  casualty  with  the  display  of  all  patient 
information  facilitating  the  best  use  of  limited  medical 
resources,  the  individual  patient  section  for  managing  the 
treatment  of  each  patient,  and  the  geospatial  section  for 
enhancing  situational  awareness  of  to  combat  related  events, 
patient  movements,  and  threats. 

The  basic  patient  information  is  presented  as  a  horizontal 
scrolling  bar  across  the  top  of  the  screen,  with  a  tile  for  each 


Fig.  2.  Tablet  user  interface  for  patient  monitoring 
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patient.  The  tile  is  color  coded  based  on  the  patient  status  and 


Video  Suiveillance 


Handheld  Sensors 
(Blackberry,  Android,  iPhone) 


Ripple-Command 
Center  View 


Fig.  3.  Proposed  future  system  with  mobile  cloudlet  and  cloud  integration,  as  described  in  [5]. 


contains  status  bars  showing  the  current  heart  rate,  dissolved 
blood  oxygen,  and  temperature  of  the  patient.  The  tiles  are  also 
used  as  a  selector  for  displaying  individual  patients  information 
in  the  individual  patient  information  display  component. 

The  individual  patients  information  is  presented  in  the  left 
half  of  the  screen.  It  contains  element  that  are  common  in 
many  electronic  triage  applications  including  a  map  of  the 
body  for  inputting  medical  notes  that  are  associated  to  an  area 
of  the  patients  body.  An  area  for  inputting  patient  vitals  and 
other  patient  identification  information.  And  an  area  for  display 
of  streaming  signals  such  as  an  electrocardiogram. 

The  right  half  of  the  screen  is  used  for  displaying  geospatial 
information.  The  need  for  this  in  a  military  context  needs  little 
explanation  as  it  is  the  primary  use  for  most  portable 
computers  used  in  combat.  In  order  to  avoid  having  operators 
carry  two  mobile  computing  devices,  for  healthcare  and 
combat  purposes,  this  application  proposes  presenting  this 
information  on  a  single  user  interface. 


III.  Future  Direction 

To  date,  Ripple  has  focused  primarily  on  the  development 
of  a  local  network  for  monitoring  local  patients.  The  next  steps 
involve  increasing  the  scope  of  our  middleware  infrastructure 
to  promote  ubiquitous  sensing  across  a  disaster  area  so  that 
medical  information  can  be  shared  with  receiving  facilities 
prior  to  patient  arrival  and  with  command  and  control  for 
improved  management  of  large  scale  disaster  response  and 
theatre  situational  awareness. 

We  envision  future  cyber  physical  systems  that  can  provide 
vital  sign  and  patient  identity  information  to  predictive 
computer  systems  that  provide  early  warnings  to  responders 
when  a  patient  is  at  increased  risk,  and  systems  that  can  fuse 
real  time  physiological  data  from  both  patients  and  responders 
with  real  time  video  from  wide  area  surveillance  systems 
providing  command  and  control  with  improved  situation 
awareness,  and  fusion  system  that  combine  smart  city 
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technologies  with  ubiquitous  health  sensing  to  facilitate 
improved  patient  transportation  during  a  disaster  response. 

In  support  of  this  vision,  we  are  proposing  an  architecture 
for  further  research  and  development.  The  architecture  shown 
in  Fig.  3  replaces  the  information  broker  with  a  mobile 
cloudlet.  The  mobile  cloudlet  is  a  subset  of  middleware  that 
would  typically  presented  in  the  cloud  for  the  purpose  of 
supporting  mission  critical  communication  that  cannot  be  put 
at  risk  by  unreliable  backhaul  connections  that  are  common  in 
disaster  areas  and  theatres  of  combat.  This  cloudlet  for 
asynchronous  connections  to  a  generic  cloud  system  that 
facilitates  the  dissemination  of  data  to  intelligent  systems.  We 
are  currently  experimenting  and  would  be  deploying  Persistent 
Surveillance  Storage  Architecture  (PSSA)  [7]  as  the  cloud 
system.  The  reasons  to  choose  PSSA  comes  from  the  evidence 
that  it  has  been  successfully  employed  in  time  critical  and  data 
sensitive  projects  like  [6]  [4],  targeted  towards  real-time 
situational  awareness  and  situational  understanding. 
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